Types of nodes in a kstore

ABSTRACT

The KStore or K is a datastore made up of a forest of interconnected, highly unconventional trees of one or more levels. Nodes in a KStore are typically comprised of at least four fields, including a pointer to an asCase node, a pointer to an asResult node, a pointer to an asCaseList and a pointer to an asResultList. Because either an asCaseList or an asResultList but not both will exist in any particular node, two new node types are created, one node comprising a node with an asCase pointer, an asResult pointer and asCaseList pointer but not including a pointer to an asResultList and one node with a pointer to an asCase node, and asResult node and an asResultList but not including a pointer to an asCaseList. Alternatively, a single node structure may exist with a pointer to a list in one field and an indicator stored in another field that indicates directly or indirectly whether the list pointed to is an asCaseList or an asResultList.

RELATED APPLICATIONS

This application claims the benefit of U.S. patent application Ser. No.11/084,996, filed Mar. 18, 2005, entitled “SYSTEM AND METHOD FOR STORINGAND ACCESSING DATA IN AN INTERLOCKING TREES DATASTORE” by MAZZAGATTI etal. which application is a Continuation of U.S. patent application Ser.No. 10/385,421, filed Mar. 10, 2003 and U.S. patent application Ser. No.11/185,620, filed Jul. 20, 2005, entitled “METHOD FOR PROCESSING NEWSEQUENCES BEING RECORDED INTO AN INTERLOCKING TREES DATASTORE,” byMAZZAGATTI. These applications are incorporated in their entiretyherein.

TECHNICAL FIELD

The present disclosure relates to data processing systems, anddatastores to such systems. In particular, the present disclosurerelates to data node types related to an interlocking trees datastore.

BACKGROUND

Data structures facilitate the organization and referencing of data.Many different types of data structures are known in the art, includinglinked lists, stacks, trees, arrays and others. The tree is awidely-used hierarchical data structure of linked nodes. Theconventional tree is an acyclic connected graph where each node has aset of zero or more child nodes and at most one parent node. A tree datastructure, unlike its natural namesake, grows down instead of up, sothat by convention, a child node is typically referred to as existing“below” its parent. A node that has a child is called the child's parentnode (or ancestor node, or superior node). In a conventional tree, anode has at most one parent. The topmost node in a tree is called theroot node. A conventional tree has at most one topmost root node. Beingthe topmost node, the root node does not have a parent. Operationsperformed on the tree commonly begin at the root node. All other nodesin the tree can be reached from the root node by following links betweenthe nodes. Nodes at the bottommost level of the tree are called leafnodes or terminal nodes. As a leaf node is at the bottommost level, aleaf node does not have any children.

SUMMARY

The KStore or K is a datastore made up of a forest of interconnected,highly unconventional trees of one or more levels. Each node in theKStore can have many parent nodes. The KStore is capable of handlingvery large amounts of highly accessible data without indexing orcreation of tables. Aspects of KStore are the subject of a number ofpatents including U.S. Pat. Nos. 6,961,733, 7,158,975, 7,213,041,7,340,471, 7,348,980, 7,389,301, 7,409,389, 7,418,455 and 7,424,480,which are hereby incorporated by reference in their entirety.

Nodes in a KStore are typically comprised of at least four fields,including a pointer to an asCase node, a pointer to an asResult node, apointer to an asCaseList and a pointer to an asResultList. Becauseeither an asCaseList or an asResultList but not both will exist in anyparticular node, two new node types can be created, one node typecomprising a node with an asCase pointer, an asResult pointer and apointer to an asCaseList and one node type comprising a node with anasCase pointer, an asResult pointer and a pointer to an asResultList.The asCaseList and asResultList fields are pointers to pointer lists andthus are the same size or larger than the asCase or asResult fields,thus the eliminated field can reduce the size of the node by about 25%.As a KStore is composed essentially entirely of nodes, eliminating thepointer to pointer list filed can reduces the size of the KStore itselfby about 25%. As KStores on the order of 50 GigaBytes are not uncommon,large amounts of space can be saved by elimination of the pointer to apointer list field. Alternatively, a single node structure may existwith a pointer to a list in one field and an indicator stored in anotherfield that indicates whether the list pointed to is an asCaseList or anasResultList.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings:

FIG. 1 is a block diagram illustrating an example of an interlockingtrees datastore (KStore or K) in accordance with aspects of the subjectmatter disclosed herein;

FIG. 2 is an example of a dataset from which the KStore of FIG. 1 wasgenerated in accordance with aspects of the subject matter disclosedherein;

FIG. 3 is a block diagram illustrating an example of a node structure ofa node of an interlocking trees datastore (KStore or K) in accordancewith aspects of the subject matter disclosed herein;

FIG. 4 is a block diagram illustrating another example of a nodestructure of a node of an interlocking trees datastore (KStore or K) inaccordance with aspects of the subject matter disclosed herein;

FIG. 5 is a block diagram illustrating an example of a node structure ofa node of an interlocking trees datastore (KStore or K) in accordancewith aspects of the subject matter disclosed herein;

FIG. 6 is a flow diagram of a method for accessing different types ofnodes in a KStore in accordance with aspects of the subject matterdisclosed herein;

FIG. 7 illustrates a generalized node data structure of a KStore datastructure in accordance with embodiments of the invention;

FIG. 8 illustrates an example of a system environment in which aspectsof the subject matter disclosed herein can be practiced; and

FIG. 9 illustrates an example of levels in a KStore in accordance withaspects of the subject matter disclosed herein.

DETAILED DESCRIPTION Overview of KStore Data Structure

A KStore or K is a datastore made up of a forest of interconnectedtrees. FIG. 9 illustrates a multi-level KStore structure 900 createdfrom the data in Dataset 1 200 of FIG. 2. The highest level (level 3)906 of the KStore 900 represents the KStore 100 illustrated in FIG. 1and represents records (e.g., Tom-Monday-103-trial-NJ). The middle level(level 2) 904 represents the field content or variables (the root nodesof KStore 100) which make up the records of level 3 906 (e.g., thevariable Tom, the variable Tuesday, etc.) and the lowest level (level 1)902 represents the universe of dataset elements that are combined tomake up the variables (e.g., the letter T, the letter o, the number 1,the number 0 and so on). It will be appreciated that multi-level KStoresof any number of levels can exist. Additional levels can be added orremoved at any time, and existing levels can be updated at any time. Forexample, an additional level (level 4, not shown) representing datasets(of which Dataset 1 200 of FIG. 2 is one dataset) can be added abovelevel 3 906. Additional records can be added to level 3 906. Additionalvariables can be added to level 2 904. Additional dataset elements(e.g., the letter v) can be added to level 1 902. Moreover, updates toone level of the KStore are propagated to other levels as required. Forexample, the addition of a record for Violet-Tuesday-100-sold-NY, wouldbe reflected in all the levels of the KStore. The record would be addedto level 3 906, the variables of level 2 904 would be updated to includethe new variables Violet and NY and the list of elemental root nodes ofthe lowest level, level 902 of FIG. 9 would be updated to includeelemental root nodes for V and Y.

The interlocking trees datastore comprises a first tree that dependsfrom a first root node (a primary root node) and may include a pluralityof branches. Each of the branches of the first tree ends in a leaf nodecalled an end product node. The first root node may represent a concept,such as but not limited to a level begin indicator (e.g., BOT orBeginning of Thought). For example, referring to FIG. 1, KStore 100includes a first tree depending from a first root node 102 and including5 branches (e.g. the topmost branch is comprised of nodes 102, 124, 128,130, 132 ending with the leaf node 104.

A second root (e.g., root node 114) of the same level of the sametrees-based datastore is linked to each leaf node of the first tree(e.g., to nodes 104, 106, 108, 110 and 112) and is called an EOT (End OfThought) node. Leaf nodes of a KStore are also called end product nodes.End product nodes include a count that reflects the number of times thesequence of nodes from BOT to EOT has occurred for the unique sequenceof nodes that end with that particular end product node. For example,node 106 with a count of 1 reflects the counts associated with the pathconnecting nodes 102, 124, 134, 138, 140 and 142. The second root (e.g.,root node 114) is a root to an inverted order of the first tree or to aninverted order of some subset of the first tree, but does not duplicatethe first tree. Node 134 is a node that is shared by the KStore paththat ends with end product node 106 and by the KStore path that endswith end product node 108. Thus the count of node 134 (4) is thecombination of the count of node 106 (1) and the count of node 108 (3).

Finally, the trees-based datastore comprises a plurality of trees of athird type in which the root node of each of these trees can bedescribed as an end product node of an immediately adjacent lower levelor as an elemental root node and may include or point to data such as adataset element or a representation of a dataset element. The root nodes116, 118, 120 and 122 are end product nodes of the immediately adjacentlower level of the KStore. It will be appreciated that not all of theroot nodes of KStore 100 are illustrated in FIG. 1 to avoid undulycluttering the Figure. The root node of each of these trees may belinked to one or more nodes in one or more branches of the unduplicatedfirst tree. The nodes of the trees-based datastore may contain pointersto other nodes in the trees-based datastore instead of data per se, andmay also contain additional fields. One such additional field may be acount field (e.g., the count field of node 120 is 6 and the count fieldof node 108 is 3). Multiple levels of the above-described tree-baseddatastore may be generated and accessed, the end products of the lowerlevel becoming the root nodes of the next level.

FIG. 1 represents KStore 100, a portion of a KStore generated fromDataset 1 200 illustrated in FIG. 2. For example, Dataset 1 200 includesa set of six instances of the record Bill Tuesday 100 sold PA. Hence thecount for the nodes 126 (Tuesday), 128 (100), 130 (sold), 132 (PA) andnode 104 (a count of the number of the Bill Tuesday 100 sold PA records)are all 6. Similarly, there is only one record for Bill Tuesday 100 soldPA thus the counts for nodes 138 (100), 140 (sold), 142 (NJ) and 106 areall 1. The count for node 124 (Bill) is 10 because there are 10 recordsin Dataset 1 that have Bill in the first field of the record. Similarlythe count of node 146 (Tom) is 5 because there are 5 records in Dataset1 that have Tom in the first field of the record.

Branches of the first tree are called asCase branches or asCase paths.AsCase paths are linked via asCase links denoted by solid lines in theFigures. Together, all the asCase paths of a KStore form the asCase treeof that level. The asCase tree depends from a first root (the primaryroot, e.g., node 102 in FIG. 1). Multiple asResult branches or asResultpaths form multiple asResult trees that depend from respective, multipleroots. AsResult paths are linked via asResult links denoted by dashedlines: (-.-.- and - - - in FIG. 1 and --- in FIG. 9). For example, inFIG. 1 a number of asResult trees are illustrated including the asResulttree comprised of root node 116 representing the dataset element Billand internal node 124 having a count field of 10 (ten) representing that10 records of the dataset that resulted in the creation of the KStore ofFIG. 1 had a value of Bill in a particular field. Another asResult treeillustrated in FIG. 1 is the asResult tree comprised of the followingnodes: root node 118 representing the dataset element Monday, which islinked by asResult links to node 134 and to node 158. The count of rootnode 118 is 9, the sum of the counts of node 134 (4) and node 158 (5).The count 9 indicates that 9 records of the dataset that resulted in thecreation of the KStore of FIG. 1 had a value of Monday in a particularfield. One instance of an asResult tree comprises the asResult treewhose root node is node 114. This root node, node 114 in FIG. 1, islinked to each end product node (e.g., nodes 104, 106, 108, 110 and112). This asResult tree can access the branches of the asCase treeterminating in end products in inverted order. This asResult tree canalso be used to define root nodes for the next level. These root nodesmay represent dataset elements for the next adjacent level, composed ofthe set of end products of the lower adjacent level.

The interlocking trees datastore may capture information aboutrelationships between dataset elements encountered in an input file bycombining a node that represents a level begin indicator (e.g., BOT)with a node that represents a dataset element to form a noderepresenting a subcomponent. A subcomponent node may be combined with anode representing a dataset element to generate another subcomponentnode in an iterative sub-process. Combining a subcomponent node with anode representing a level end indicator may create a level end productnode. The process of combining a level begin node with a dataset elementnode to create a subcomponent and combining a subcomponent with adataset element node and so on may itself be iterated to generatemultiple asCase branches in a level. AsResult trees may also be linkedor connected to nodes in the asCase tree, such as, for example, by aroot node of an asResult tree pointing to one or more nodes in theasCase tree.

FIG. 7 illustrates the data fields of a typical node, e.g., node 730 ofthe interlocking trees data structure. Node 730 can represent anelemental root node, subcomponent node or end product node. When a newnode is built in an interlocking datastore, memory is allocated for thenew node as shown in FIG. 7. A plurality of pointers can then be storedin the allocated memory. The new node is defined by setting the asCasepointer (pointer to Case) 706 to point to the previous node in the pathand setting the asResult pointer (pointer to Result) 708 to point to theroot node. Thus, for example, if node 730 represents the subcomponentnode 124 of the interlocking trees datastore shown in FIG. 1, the asCasepointer 706 would point to the BOT node, node 102 and the asResultpointer 708 would point to the Bill root node, node 116. The pointer toasCaseList 710 is a pointer to a list of the subcomponent nodes or endproduct nodes for which the node represented by the node 730 is theasCase node. For example, the asCaseList for node 134 would includepointers to nodes 136 and 138. It will be appreciated that the pointerto asCaseList, field 710 will be null for the elemental nodes and forend product nodes. The pointer to asResultList 712 is a pointer to alist of the subcomponents nodes or end product nodes for which the noderepresented by the exemplary node 730 is the asResult node. For example,the asResultList for node 124 would be empty. It will be appreciatedthat the pointer to asResultList field 712 will be null for allsubcomponent nodes. The asResultList of root node 118 (Monday) includespointers to nodes 158 and 134 tree. The nodes of the interlocking treesdatastore can also include one or more additional fields 714. Theadditional fields 714 may be used for an intensity or count associatedwith the node. A count may be incremented or decremented to record thenumber of times that a node has been accessed or traversed or to recordthe number of times it was encountered or received in an input dataset.The additional fields 714 may be used for a list of all the elementalroot nodes represented by the node or for any number of different itemsassociated with the structure. Another example of a parameter that canbe stored in an additional field 716 is the particle value representinga dataset element for an elemental root node. If the node is anelemental root node it may also contain a field 716, comprising thevalue of the dataset element it represents or a pointer to the value ofthe dataset element it represents.

As nodes are created, asCase and asResult links may be simultaneouslygenerated at each level and asCaseLists and asResultLists may begenerated and updated. As described above, an asCase link represents alink to the first of the two nodes from which a node is created. Forexample, referring to FIG. 1, the asCase link of node 124 points to nodeBOT 102. It will be appreciated that asCase branches of the asCase treesmay be created by generation of the asCase links as the input isprocessed. The asCase branches of each level thus provide a directrecord of how each subcomponent and end product of the level wascreated. Hence the asCase branches can be used to represent one possiblehierarchical relationship of nodes in the asCase tree. For example ifthe data received by an interlocking trees generator is data concerningsalesmen who sell products identified by product numbers in states ofthe United States, a particular input dataset may include the tworecords:

Tom sold 100 PA Bill sold 40 NJwhere Tom and Bill are salesmen, 100 and 40 are product numbers and PAand NJ are states in which the salesmen sold their products. The asCasetree generated from this input may comprise a view of the data in thecontext of “state information with the context of salesman” context.

An asResult link represents a link to the second of the two nodes fromwhich a node is created. For example, the asResult link of node 124points to node 116 (Bill). The generation of the asResult links createsa series of interlocking trees where each of the asResult trees dependfrom a root comprising a dataset element. This has the result ofrecording all encountered relationships between the root nodes and thenodes of the asCase trees in the KStore. That is, the asResult treescapture all the possible contexts of the nodes of the interlockingtrees. If, for example, the input to the interlocking trees datastoregenerator comprises a universe of sales data including salesman name,day of the week, product number and state, the resulting asResult linksof the generated interlocking trees datastore could be used to extractinformation such as: “What salesmen sell in state X”, “How many itemswere sold on Monday?” “How many items did Salesman Bill sell on Mondayand Tuesday?” and the like, all from the same interlocking treesdatastore, without creating multiple copies of the datastore, andwithout creating indexes or tables.

It will be appreciated that this information is determinable from thestructure of the interlocking trees datastore itself rather than frominformation explicitly stored in the nodes of the structure. Paths canbe traversed backwards towards the root node to determine if thesubcomponent or end product belongs to a particular category or class ofdata. Links between nodes may be bidirectional. For example, a root nodefor the dataset element “Monday” (e.g. root node 118) may include apointer to a subcomponent BOT-Bill-Monday (e.g., node 134) in node 118'sasResultList while the node BOT-Bill-Monday, node 134 may include apointer to the node Monday, node 118, as its asResult pointer and so on.Furthermore, by following asCase links of the nodes containing a desireddataset element, other subcomponents and end products containing thedesired dataset element can be found along the branch of the asCasetree. It will be appreciated that the described features cause thedatastore to be self-organizing.

Types of Nodes in a KStore

As described above, a generalized node in a KStore can be used toinstantiate any node in a KStore. However, subcomponent nodes and BOTnodes have entries only in the pointer to asCaseList field because thereare no subcomponent nodes which are the asResult node of other nodes.Moreover, elemental root nodes and end product nodes will not have apointer to an asCaseList in the pointer to asCaseList field because anelemental root node or end product node will not be the Case node foranother node. The one exception is the BOT node or primary root node,which will have a pointer to an asCaseList in its asCaseList field. Tocreate a more memory efficient KStore, in accordance with aspects of thesubject matter disclosed herein, the unused pointer list pointer isomitted from the nodes of the KStore. Two different node structures canbe defined, one having the field for the asCaseList pointer and no fieldfor the asResultList pointer and one having the field for theasResultList pointer and no field for the asCaseList pointer.Alternatively, one node structure can be defined, the node structurecomprising a field for a pointer to the asCase node, a field for apointer to the asResult node, a field for a pointer to a list ofpointers and a field for an indicator for the type of the list ofpointers the pointer points to or a field for an indicator for the typeof node.

FIG. 3 300 illustrates a first structure of two different nodestructures of nodes of a KStore. Node 300, which can be a BOT or primaryroot node or subcomponent node, has a field for a pointer to an asCasenode, field 706, a field for a pointer to an asResult node, field 708, afield for a pointer to an asCaseList, field 710. Node 300 may alsoinclude one or more additional fields, field 714 and a field for a valueor a pointer to a value, field 716 but does not have a field for apointer to an asResultList.

FIG. 4 400 illustrates a second structure of two different nodestructures of nodes of a KStore. Node 400, which can be an end productnode or an elemental root node except for the BOT node. Node 400 has afield for a pointer to an asCase node, field 706, a field for a pointerto an asResult node, field 708, a field for a pointer to anasResultList, field 712. Node 300 may also include one or moreadditional fields, field 714 and a field for a value or a pointer to avalue, field 716 but does not have a field for a pointer to anasCaseList.

FIG. 5 500 illustrates a node structure of a node of a KStore. Node 500can represent an end product node, an elemental root node, a BOT node,an EOT node, or a subcomponent node. Node 500 has a field for a pointerto an asCase node, field 706, a field for a pointer to an asResult node,field 708, a field for a pointer to a list, field 718 and a field 720that includes an indicator for the type of node it is. Node 500 may alsoinclude one or more additional fields, field 714 and a field for a valueor a pointer to a value, field 716. The field 718 of the noderepresented by node 500 may have either a pointer to an asCaseList or apointer to an asResultList but cannot have both pointers to anasCaseList and an asResultList.

FIG. 8 illustrates an example of a KStore computing environment in whichKStores may be implemented. The computing environment may include one ormore networked or unnetworked computers capable of implementing andprocessing KStores on which one or more of the following reside: a KEngine 14, one or more KStores such as KStore 12 and KStore 13, a LearnEngine 26, one or more data sources 30, a utility 16, an applicationprogramming interface (API) utility 23, one or more graphical userinterfaces (e.g., GUI 38, GUI 36) and one or more applications such asapplication 34. One or more of: K Engine 14, Learn Engine 26, utility16, application programming interface (API) 23, graphical userinterfaces (e.g., GUI 38, GUI 36) and application 34 may be executed bythe processor of a computer.

The Learn Engine 26 may receive data from many types of input datasources and may transform the received data to particles suitable to thetask to which the KStore being built will perform. For example, if thedata being sent to the KStore is information from a field/record typedatabase, particular field names may be kept, changed, or discarded,depending on the overall design of the KStore the user is creating.After breaking down the input into appropriate particles, the LearnEngine 26 may make appropriate calls to the K Engine 14 and pass thedata in particle form in a way that enables the K Engine 14 to put itinto the KStore structure,

API utilities such as API utility 23 receive inquiries and transform thereceived inquiries into calls to the K Engine, to access the KStoredirectly or to update associated memory. In the event that a query isnot to be recorded in the structure of a KStore a LEARN SWITCH may beturned off. In the event that a query is to be recorded in the structureof the KStore, (as in Artificial Intelligence applications, for example)the LEARN SWITCH may be turned on. API utilities may get informationfrom the KStore using predefined pointers that are set up when theKStore is built (rather than by transforming the input into particlesand sending the particles to the KEngine). For instance, a field maypoint to the Record End of Thought (EOT) node, the Field EOT node, theColumn EOT node and the Beginning Of Thought (BOT) node. This field maybe associated with the K Engine, and may allow the K Engine to traversethe KStore using the pointers in the field without requiring the APIUtility to track this pointer information.

Within the KStore computing environment information may flowbi-directionally between the KStore or KStores, a data source 30 and anapplication 34 by way of a K Engine 14. The transmission of informationbetween the data source 30 and the K Engine 14 may be by way of a learnengine 26, and the transmission of information between the application34 and the K Engine 14 may be by way of an API or API utility engine 23.Data source 30 and application 34 may be provided with graphical userinterfaces 36, 38 to permit a user to communicate with the system.

Objects or other types of system components such as learn engine 26 andthe API utility engine 23 may be provided to service learn and querythreads so that applications and interfaces of any kind can address,build and use the KStore(s). Learn engine 26 may provide an ability toreceive or get data in various forms from various sources on the samecomputer or on different computers connected via a network and to turnit into input particles that the K Engine 14 can use. The API Utilityengine may provide for appropriate processing of inquiries received byapplication software of any kind. The API utility engine 23 and thelearn engine 26 get information from and/or put information into aKStore. It will be understood by those of skill in the computer artsthat software objects can be constructed that will configure thecomputer system to run in a manner so as to implement the attributes ofthe objects. It is also understood that the components described abovemay be created in hardware as well as software.

FIG. 6 illustrates a method 600 of accessing nodes in a KStore, as maybe performed by a KStore engine 14. At 772 a node is accessed. At 774the type of the node is determined. At 778, in response to determiningthat the node is a subcomponent node or a BOT node at 706, the pointerin the pointer field is determined to be a pointer to an asCaseList. At780, in response to determining that the node is a subcomponent node ora BOT node at 706, the pointer in the pointer field is determined to bea pointer to an asResultList. At 776, the type of the node can bedetermined by examination of field 720, or by determining that the nodeis a node of the type illustrated in FIG. 3 or by determining that thenode is a node of the type illustrated in FIG. 4.

The various techniques described herein may be implemented in connectionwith hardware or software or, where appropriate, with a combination ofboth. Thus, the methods and apparatus described herein, or certainaspects or portions thereof, may take the form of program code (i.e.,instructions) embodied in tangible media, such as floppy diskettes,CD-ROMs, hard drives, or any other machine-readable storage medium,wherein, when the program code is loaded into and executed by a machine,such as a computer, the machine becomes an apparatus for practicingaspects of the subject matter disclosed herein. In the case of programcode execution on programmable computers, the computing device willgenerally include a processor, a storage medium readable by theprocessor (including volatile and non-volatile memory and/or storageelements), at least one input device, and at least one output device.One or more programs that may utilize the creation and/or implementationof domain-specific programming models aspects, e.g., through the use ofa data processing API or the like, may be implemented in a high levelprocedural or object oriented programming language to communicate with acomputer system. However, the program(s) can be implemented in assemblyor machine language, if desired. In any case, the language may be acompiled or interpreted language, and combined with hardwareimplementations.

While the subject matter disclosed herein has been described inconnection with the figures, it is to be understood that modificationsmay be made to perform the same functions in different ways. Whileinnumerable uses for this invention may be found, and significantvariability in the form and manner of operation of this invention aredescribed and will occur to those of skill in these arts, the inventionis not limited in scope further than as set forth in the followingclaims.

1. A system for accessing nodes in a KStore comprising: a KStore enginethat accesses a node in the KStore, the KStore comprising a multi-levelinterlocking trees datastore comprising elemental root nodesrepresenting dataset elements, subcomponent nodes and end product nodeslinked by asCase and asResult bi-directional links that create asCaseand asResult paths within the multi-level interlocking trees datastore,wherein an asCase path comprises a sequence of subcomponent nodes linkedwith bi-directional asCase links ending with an end product noderepresenting dataset elements of an adjacent upper level and where eachsubcomponent node in the asCase path has a bi-directional asResult linkto an elemental root node or end product node comprising an asResulttree, wherein the KStore engine accesses a node comprising at least afield comprising a pointer to an asCase node, a field comprising apointer to an asResult node, and a field comprising a pointer to a list.2. The system of claim 1, wherein the accessed node further comprises anode type indicator field.
 3. The system of claim 2, wherein the KStoreengine, in response to determining from the node type indicator of theaccessed node that the accessed node is a BOT node or a subcomponentnode, determines that the field comprising a pointer to a list comprisesa pointer to an asCase List.
 4. The system of claim 2, wherein theKStore engine, in response to determining from the node type indicatorof the accessed node that the accessed node is an end product node or anelemental root node, determines that the field comprising a pointer to alist comprises a pointer to an asResultList.
 5. The system of claim 2,wherein the node type indicator field indicates that the fieldcomprising a pointer to a list points to an asCaseList.
 6. The system ofclaim 2, wherein the node type indicator field indicates that the fieldcomprising a pointer to a list points to an asResultList.
 7. The systemof claim 1, wherein the KStore engine determines that the accessed nodeis a node of a first type comprising a pointer to a Case node, a pointerto a Result node and a pointer to an asCaseList or wherein the KStoreengine determines that the accessed node is a node of a second typecomprising a pointer to a Case node, a pointer to a Result node and apointer to an asResultList.
 8. A method for accessing a node of a KStorecomprising: accessing the node of the KStore via a KStore engine runningon a KStore computer; determining a type of node of the accessed node,wherein the KStore is comprised of nodes, wherein each node of theKStore comprises a field of a plurality of fields, wherein the fieldcomprises a value or a pointer to a value, the value comprising thedataset element represented by the elemental root node, wherein a KStorecomprises an interlocking trees datastore comprising elemental rootnodes, subcomponent nodes and end product nodes linked by asCase andasResult bidirectional links that create asCase and asResult pathswithin the interlocking trees datastore, wherein an asCase pathcomprises a sequence of subcomponent nodes linked with bi-directionalasCase links ending with an end product node and where each subcomponentnode in the asCase path has a bi-directional asResult link to anelemental root node or end product node comprising an asResult tree. 9.The method of claim 8, wherein in response to determining the accessednode is a BOT node, a field of the accessed node points to anasCaseList.
 10. The method of claim 8, wherein in response todetermining the accessed node is a subcomponent node, a field of theaccessed node points to an asCaseList.
 11. The method of claim 8,wherein in response to determining the accessed node is an elementalroot node, a field of the accessed node points to an asResultList. 12.The method of claim 8, wherein in response to determining the accessednode is an end product node, a field of the accessed node points to anasResultList.
 13. The method of claim 8, wherein the type of the node isdetermined by determining that the accessed node is one of: a nodecomprising a pointer to an asCase node, a pointer to an asResult nodeand a pointer to an asCaseList; or a node comprising a pointer to anasCase node, a pointer to an asResult node and a pointer to anasResultList.
 14. A computer-readable medium comprisingcomputer-executable instructions that when executed, cause a computingenvironment to: access a node of a KStore, wherein the KStore comprisesan interlocking trees datastore comprising elemental root nodes,subcomponent nodes and end product nodes linked by asCase and asResultbi-directional links that create asCase and asResult paths within theinterlocking trees datastore, wherein an asCase path comprises asequence of subcomponent nodes linked with bi-directional asCase linksending with an end product node and where each subcomponent node in theasCase path has a bi-directional asResult link to an elemental root nodeor end product node comprising an asResult tree; and determines a typeof the accessed node.
 15. The computer-readable medium of claim 14,comprising further computer-executable instructions that when executedcause the computing environment to: determines that a field comprising apointer to a list points to an asCaseList in response to determining theaccessed node is a BOT or subcomponent node.
 16. The computer-readablemedium of claim 14, comprising further computer-executable instructionsthat when executed cause the computing environment to: determines that afield comprising a pointer to a list points to an asResultList inresponse to determining the accessed node is an elemental root node oran end product node.
 17. The computer-readable medium of claim 14,comprising further computer-executable instructions that when executedcause the computing environment to: determine the type of the accessednode by examining a field in the accessed node comprising a type of nodeindicator.
 18. The computer-readable medium of claim 14, comprisingfurther computer-executable instructions that when executed cause thecomputing environment to: determine the type of the accessed node bydetermining the accessed node comprises a field comprising a pointer toa Case node, a pointer to a result node and a pointer to an asCaseList.19. The computer-readable medium of claim 14, comprising furthercomputer-executable instructions that when executed cause the computingenvironment to: determine the type of the accessed node by determiningthe accessed node comprises a field comprising a pointer to a Case node,a pointer to a result node and a pointer to an asResultList.